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IN THE SPECIFICATION : 

At page 1, prior to line 3, please insert the following new paragraph and 
headings: 

CROSS-REFERENCE TO RELATED APPLICATION 

This is the U.S. National Stage of International Application Number 
PCT/FI2003/000763 filed October 15, 2003 and published in English on April 29, 
2004 under International Publication Number WO 2004/036837 and claiming 
priority from Finnish application 20021832 filed October 15, 2002. 

BACKGROUND OF THE INVENTION 

1. Technical Field 

At page 1, prior to line 8, please add the following heading and amend the 
paragraphs beginning on line 8 through page 2, line 2 as follows: 

2. Discussion of Related Art 

3 GPP (3 rd Generation Partnership Project) has recently published a specification for 
the 3 GPP system comprising either UTRAN (UMTS Terrestrial Radio Access 
Network) or GERAN (GSM/EDGE Radio Access Network) as a radio access 
network. The specification defines a new broadcast/multicast service titled MBMS 
(Multimedia Broadcast/Multicast Service) [1]. MBMS basic architecture is 
illustrated in figure 1 wherein CBC (Cell Broadcast Gentre Center ) 102, CSE (Camel 
Service Environment) 108, OSA/SCS (Open Service Access) 1 12 and related 
reference points can be considered as optional functionalities. Accordingly, 
mandatory components for realizing a MBMS service are described next in reference 
to [2]. 

The SGSN (Serving GPRS Support Node) 120 executes user specific service control 
functions, concentrates individual users of the same MBMS service into a single 
MBMS service and maintains a single connection with the source of the MBMS 
data. The SGSN 120 may also authenticate users and authoris e authorize the usage of 
services based on subscription data from the HLR (Home Location Register) 106. 
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The GGSN (Gateway GPRS Support Node) 122 terminates the MBMS GTP (GPRS 
Tunneling Protocol) tunnels from the SGSN 120 and links these tunnels via IP 
(Internet Protocol) multicast with the MBMS data source. The BM-SC 
(Broadcast/Multicast Service GentFeCenter) 1 10 is an MBMS data source. The 
architecture also accepts other MBMS broadcast/multicast data sources and internal 
data sources 104 may directly provide their data. Data delivery by external sources 
126 is controlled by Border Gateways (BG) 124 which may allow for example data 
from single addresses and ports to pass into the PLMN (Public Land Mobile 
Network) for delivery by an MBMS service. MBMS data may be scheduled in the 
BM-SC 1 10, for example, to be transmitted to the user every hour. It offers 
interfaces which can be utilized by a content provider 104, 1 14 in requesting data 
delivery to users. The BM-SC 1 10 may autheftseauthorize and charge the content 
provider 104, 1 14. The Gmb reference point between BM-SC 1 10 and GGSN 122 
enables the BM-SC 1 10 to exchange MBMS service control information with the 
GGSN 122. The Gmb reference point exists in order to carry the MBMS service 
information but it may not always be necessary to use the Gmb for each service. 
MBMS service can be delivered to user equipment (UE) 1 16, 128 such as a mobile 
terminal over GERAN 130 or UTRAN 118. 

At page 2, please amend the paragraph beginning on line 14 as follows: 

The SGSN 120 may use CAMEL (Customised Application for Mobile network 
Enhanced Logic) to handle pre-paid services, e.g. credit checking for on-line 
charging. The Cell Broadcast Genfr eCenter (CBC) 102 may be used to announce 
MBMS services to the users. The BM-SC 1 10 may exploit OSA-SCS 1 12 to interact 
with third parties. For the terminal split, MBMS shall be able to interoperate with an 
IP multicast client software on the terminal. More detailed information about MBMS 
service activation/release models, data transfer, functionalities of network elements, 
radio interface bearer set-up/release, QoS (Quality of Service), security issues etc. 
can be found in the references [1] and [2]. 

At page 2, please amend the paragraph beginning on line 4 as follows: 

TheGb interface on the other hand connects the GERAN 130 to 2G SGSN 120 and 
the functional split between the BSS 130 (Base Station System, -radio access 
network e.g. GERAN) and the SGSN 120 is different from the UTRAN/GERAN Iu 
mode. For example, ciphering is done in the core network (SGSN). Also the protocol 
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architecture illustrated in figure 3 being described more thoroughly later in the text 
and the procedures between the SGSN and the BSS differ from the Iu case. 

At page 4, please add the following new heading on line 1 5 and amend the 
paragraph beginning on line 16 as follows: 

DISCLOSURE OF INVENTION 

An object of the present invention is to alleviate the aforesaid deficiencies and 
provide an addressing mechanism for routing MBMS data over the Gb interface 
between the SGSN 120 and BSS 130. Additionally, a flow control mechanism is 
needed for MBMS services as the bitrate they typically require may be relatively 
high and varying causing potential problems also for other traffic delivered by the 
BSS 130. The object is achieved by introducing a concept of MBMS 
speeifle MBMS-specific packet flow context (PFC), called MBPFC 
(Multicast/Broadcast Packet Flow Context) hereinafter, to the Gb interface with 
functionalities partly corresponding the ones MBMS RAB provides in the Iu mode. 
The proposed concept thus allows reuse of some already-existing procedures and 
resolves certain Gb interface specific problems. 

At page 5, prior to line 25, please add the following new heading: 

BRIEF DESCRIPTION OF THE DRAWINGS 

At page 6, please add the following heading prior to line 13 and amend the 
paragraph beginning on line 14 as follows: 

BEST MODE FOR CARRYING OUT THE INVENTION 

Figures 1-4 were already covered in conjunction with the description of the p rior art. 
The signalling chart in figure 4 presenting the MBMS service activation is feasible 
also in this case wha twhen it comes to phases 402-414 preceding the RAB set-up. 

At page 8, please amend the paragraphs beginning on line 9 through page 10, 
line 17 as follows: 
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Figures 5-7 disclose one option for enabling MBMS data routing and flow control 
between the SGSN 120 and BSS 130 in accordance with the invention. In a general 
sense, a procedure partly congruent with the PFC concept described above can be 
applied by creating a MBPFC for each MBMS service, a group of services or a 
group of terminals. From the SGSN's standpoint said group of terminals may, for 
example, belong to a same multicast group and reside behind a common BVC. The 
group, which typically contains at least two terminals, may receive data from a 
single source, e.g. an MBMS service, or from multiple sources. Occuring randomly 
it is still possible to have only one user (-one terminal) in the group though. In any 
case, the MBPFC is not logically connected to any individual terminal/associated 
with' any individual TLLI (or TMSI / P-TMSI). felna multicast scenario the group 
for which the MBPFC is logically connected may be identified by a specific ID (e.g. 
a multicast ID). An MBMS specific PFI such as the multicast ID can also be sent to 
the terminals belonging to the multicast group for identifying the incoming MBMS 
flow. However, this may not be necessary as the identification can also be done in 
some other way (MBMS ID etc). The main use of an MBPFC is according to the 
invention to serve as an addressing mechanism between the SGSN 120 and the BSS 
130 and facilitate using flow control in the Gb interface. In the BSS 130 the MBPFC 
is mapped to an appropriate logical channel so that the announced MBMS service is 
sent on the channel indicated to users in the service announcement procedure, 
wherein network broadcasts information e.g. about the frequency, time slot, and 
possibly TDMA frame when a particular service is scheduled over the radio 
interface. 

The creation of an MBPFC can be executed as follows, see figure 5 A. The SGSN 
120 may initiate the procedure without any specific trigger from the BSS 130 side. 
For example, when the network establishes a new MBMS service or when the data is 
actually to be transferred the SGSN 120 initiates the creation of an MBPFC relating 
to the service/multicast group. This can be done in conjunction with the service 
announcement or later on. The SGSN 120 requests for the creation of the MBPFC by 
sending a CREATE-MBPFC PDU 504 to the BSS 130 including a PFI to be used for 
the PFC identification. The BSS 130 (in the GERAN case the network elements 
within the BSS executing this task are the RNCs), responds with a CREATE- 
MBPFC- ACK PDU 508 or corresponding NACK if the MBPFC cannot be created. 
As the proposed method *«mi*4s is reminiscent of the one for creating a standard 
PFC with DOWNLOAD-BSS-PFC (optional), CREATE-BSS-PFC and CREATE- 
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BSS-PFC-ACK messages, the existing standard procedure can also be exploited in 
this MBMS specific case, anyhow recalling that the essential difference is founded 
on a fact that the MBPFC is not logically connected to an individual terminal unlike 
the standard PFC. The network maps the PFC/PFI to a MBMS service/multicast 
group and it is also possible, although not advisable, to position all MBMS services 
into a single MBPFC. In that case different services cannot be treated independently 
and they may delay each other etc. The SGSN 120 and BSS 130 maintain entities, 
e.g. memory tables, of existing MBMS service/multicast group<->PFC/PFI 
mappings in order to route and control the flow of the data to be transferred and, in 
the BSS 130, to further pass the received data over an appropriate (e.g. announced) 
logical channel to terminal(s) either as a broadcast or PTM (Point-To-Multipoint, 
e.g. multicast) transmission. 



At page 10, please amend the paragraph beginning on line 6 as follows: 

The SGSN 120 shall preferably perform flow control on each BVC, on each MBPFC 
and on some/all MBMS services as a whole, see figure 7. The flow control is 
performed first on each LLC-PDU (to be included in a UNITDATA PDU) by an 
MBPFC specific flow control mechanism 702, then by an aggregate flow control 
mechanism 704 and finally by a BVC flow control mechanism 706. BVC flow 
control (typically corresponding a cell) parameters concerning both standard PFCs as 
well as MBPFCs are received from the BSS 130 in a FLOW-CONTROL-BVC PDU 
described in the reference [4]. MBPFC flow control parameters can in principle be 
received from the BSS in a FLOW-CONTROL-PFC message as in a normal PFC 
case but the binding of the PFC with an individual terminal does not naturally apply. 
However, the BSS 130 may, for example, estimate an average profile of terminals 
receiving the services and inform the profile or relating parameters to the SGSN 120 
for derivation of MBPFC specific flow control definitions. On the other hand, a set 
of rules may have been programmed in the BSS 130 indicating desired parameters 
(e.g. limit values for data leakage) for receiving services of varying typetypes and 
based on that information, provide MBPFC specific parameters to the SGSN 120. As 
an third option, the SGSN 120 may define MBPFC flow control parameters based on 
some service related data or its current status (e.g. load). An entity called MBMS 
service block 708 may be created, under which there would be a number of MBPFCs 
carrying different MBMS services, to form an aggregate flow control level 704 
comprising at least one block 708 but one option is to perform only PFC and BVCI 
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flow control resulting that the aggregate level 704 in figure 7 does not exist. 
Secondly, if only a single PFC is created for all MBMS services as mentioned 
earlier, the situation remains the same. The SGSN 120 may construct the MBMS 
service blocks 708 by, for example, dividing the MBMS services into a number of 
groups (linked to blocks) based on the information about service/content type, 
content provider and service delivery requirements. This information, which can also 
be utilized in the creation of MBPFC flow control definitions, may be received, from 
a network element like the GGSN 122 or it can be derived internally either explicitly 
or implicitly from the MBMS data or relating ancillary information. 

At page 11, please amend the paragraph beginning on line 16 as follows: 

The scope of the invention is disclosed in the following independent claims. 
However, utilized messages, network elements, method and procoduro stops 
ete procedural steps, etc., may vary depending on the current scenario, still 
converging to the basic ideas of the invention. Therefore, the invention is not strictly 
limited to the embodiments described above. 

At page 12, please amend the reference beginning on line 2 as follows: 



[ 1 ] 3 GPP TS 222.H6 22.146 V6.0.0 Technical Specification Group 

Services and System Aspects; Multimedia Broadcast/Multicast Service; Stage 
1 Release 6 (2002-6), URL: http://www.3gpp.org, 3 GPP 2002 
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